Patterns: represent constants as valtrees #144591

RalfJung · 2025-07-28T16:23:45Z

Const patterns are always valtrees now. Let's represent that in the types. We use ty::Value for this since it nicely packages value and type, and has some convenient methods.

Cc @Nadrieril @BoxyUwU

rustbot · 2025-07-28T16:23:49Z

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-07-28T16:23:51Z

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred in match lowering

cc @Nadrieril

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in match checking

cc @Nadrieril

RalfJung · 2025-07-28T16:25:07Z

compiler/rustc_mir_build/src/builder/matches/test.rs

                let tcx = self.tcx;
                let success_block = target_block(TestBranch::Success);
                let fail_block = target_block(TestBranch::Failure);

-                let mut expect_ty = value.ty();
+                let mut expect_ty = value_ty;
+                let value = Const::Ty(value_ty, ty::Const::new_value(tcx, value, value_ty));


Oddly, constructing a mir::Const from a valtree requires the type twice...

Const::Ty storing more than just a ty::Const is kinda meh yeah. This came about when we stopped storing a Ty alongside all ty::Consts. Removing the ty field from Const::Ty would require updating the function mir::Const::ty( to take either a TypingEnv so we can lookup the type of const parameters, and so that we can normalize the resulting type from type_of unevaluated constants and const generic parameter declarations

It is odd that mir::Const and ty::Value know their type but ty::Const does not... but I won't touch this now, there's probably a reason we ended up here.^^

you can likely find a bit of context in #125958 as to how ty::Const wound up the way it did. For ty::Const only ty::Value needs a Ty because everything else we can "figure out" the type from the environment we're in or from the ty::Const itself.

I would expect that mir::Const::Unevaluated doesnt really need to store a Ty either as it should just be equivalent to type_of(uv.def).instantiate(uv.args) and then a normalization call 🤔

tests/ui/thir-print/thir-tree-loop-match.stdout

RalfJung · 2025-07-28T16:31:39Z

compiler/rustc_pattern_analysis/src/rustc.rs

+                let max = ty.numeric_max_val(cx.tcx).unwrap();
+                let max = ty::ValTree::from_scalar_int(cx.tcx, max.try_to_scalar_int().unwrap());


This is a kind of silly dance. Maybe numeric_max_val should just return a ScalarInt?

RalfJung · 2025-07-28T21:18:04Z

@rust-timer queue
@bors try

rust-bors · 2025-07-28T21:18:07Z

⌛ Trying commit b39c019 with merge e111586…

To cancel the try build, run the command @bors try cancel.

Patterns: represent constants as valtrees

rust-bors · 2025-07-28T23:33:17Z

☀️ Try build successful (CI)
Build commit: e111586 (e1115864e9f2387f19e755d0a8a30df5a8933f7c, parent: e3514bde96d2d13586337a48db77fa64b850d249)

BoxyUwU · 2025-07-29T00:41:21Z

We could use ty::Value which nicely pairs up a valtree and a value -- however, a const pattern can be a raw pointer, which is not a valid "type system value".

Given that we evaluate all const patterns by going through a ty::Const or ty::UnevaluatedConst we already don't get the property that ty::Const s only have to deal with stuff in const generics. I'm not sure if this is desirable or not and I think I need to finish adt_const_params before I'll be able to tell for sure 🤔

Regardless, with this in mind I think using ty::Value is fine, we can always swap it out for a different Ty/ValTree tuple down the road if it winds up being a problem. It doesn't seem worth making code-quality worse in order to try and maintain a property that doesn't even hold rn and I don't know how we even would do so nicely :D

rust-timer · 2025-07-29T01:02:57Z

Finished benchmarking commit (e111586): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.0%	[-2.8%, -0.1%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.0%	[-2.8%, -0.1%]	7

Max RSS (memory usage)

Results (secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.9%	[-3.1%, -2.7%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -3.3%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.3%	[-3.3%, -3.3%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 468.526s -> 467.78s (-0.16%)
Artifact size: 376.81 MiB -> 376.82 MiB (0.00%)

RalfJung · 2025-07-29T07:01:42Z

compiler/rustc_pattern_analysis/src/rustc.rs

@@ -907,7 +891,7 @@ impl<'p, 'tcx: 'p> PatCx for RustcPatCtxt<'p, 'tcx> {
    type Ty = RevealedTy<'tcx>;
    type Error = ErrorGuaranteed;
    type VariantIdx = VariantIdx;
-    type StrLit = Const<'tcx>;
+    type StrLit = ty::Value<'tcx>;


Oddly it seems like I can just change this type and nobody cares...

RalfJung · 2025-07-29T07:03:57Z

compiler/rustc_mir_build/src/builder/matches/mod.rs

@@ -1373,16 +1373,16 @@ enum TestBranch<'tcx> {
    /// Success branch, used for tests with two possible outcomes.
    Success,
    /// Branch corresponding to this constant.
-    Constant(Const<'tcx>, u128),
+    Constant(ty::Value<'tcx>, u128),


This is the one place where dropping the type and just using a ValTree would work... but for consistency I kept it here, too.

RalfJung · 2025-07-29T07:04:33Z

@bors try
@rust-timer queue

Patterns: represent constants as valtrees

rust-bors · 2025-07-29T07:04:37Z

⌛ Trying commit 9f3f015 with merge 13cfa7a…

To cancel the try build, run the command @bors try cancel.

rust-bors · 2025-07-29T09:20:47Z

☀️ Try build successful (CI)
Build commit: 13cfa7a (13cfa7a8f9f23454b856e7ac703311674fe94229, parent: cb6785f73df1aa3f558796a22a4ab9652cf38e26)

Co-authored-by: Boxy <[email protected]>

RalfJung · 2025-08-14T07:45:00Z

@rustbot ready

BoxyUwU · 2025-08-14T12:50:22Z

@bors r+ rollup=never

I don't know why the perf regression is there 🤔 I have to assume its just noise from boring code movement changes.

bors · 2025-08-14T12:50:25Z

📌 Commit 2330afa has been approved by BoxyUwU

It is now in the queue for this repository.

BoxyUwU · 2025-08-14T13:25:42Z

ah actually @RalfJung can you update the PR description? its a bit out of date now as we're using ty::Value

bors · 2025-08-15T05:49:58Z

⌛ Testing commit 2330afa with merge 8800ec1...

bors · 2025-08-15T09:12:01Z

☀️ Test successful - checks-actions
Approved by: BoxyUwU
Pushing 8800ec1 to master...

github-actions · 2025-08-15T09:15:08Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 3507a74 (parent) -> 8800ec1 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 8800ec16657b24ad8a2f443c133bf0b56ae76033 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-apple-1: 6428.2s -> 9301.0s (44.7%)
dist-aarch64-apple: 5388.6s -> 6702.5s (24.4%)
pr-check-1: 1448.5s -> 1717.3s (18.6%)
i686-gnu-2: 5392.1s -> 6201.2s (15.0%)
aarch64-apple: 6410.0s -> 5535.6s (-13.6%)
dist-aarch64-windows-gnullvm: 4415.5s -> 4868.2s (10.3%)
dist-x86_64-apple: 9657.9s -> 10625.3s (10.0%)
pr-check-2: 2983.1s -> 2692.9s (-9.7%)
dist-apple-various: 5505.5s -> 4982.4s (-9.5%)
x86_64-gnu-aux: 7397.4s -> 6712.7s (-9.3%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-08-15T10:21:38Z

Finished benchmarking commit (8800ec1): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	5.3%	[5.3%, 5.3%]	1
Regressions ❌ (secondary)	0.7%	[0.2%, 1.0%]	9
Improvements ✅ (primary)	-2.7%	[-3.2%, -2.2%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-3.2%, 5.3%]	7

Max RSS (memory usage)

Results (primary 2.0%, secondary -1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.4%, -2.9%]	3
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Cycles

Results (primary 4.8%, secondary -1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	4.8%	[4.8%, 4.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-1.7%, -1.7%]	1
All ❌✅ (primary)	4.8%	[4.8%, 4.8%]	1

Binary size

Results (primary 0.5%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.5%, 0.5%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.1%]	6
All ❌✅ (primary)	0.5%	[0.5%, 0.5%]	3

Bootstrap: 469.244s -> 470.592s (0.29%)
Artifact size: 377.39 MiB -> 377.42 MiB (0.01%)

RalfJung · 2025-08-15T17:55:32Z

That clap_derive regression is new (didn't show up in the prior bench runs here)... but that benchmark seems to have fluctuated with the last few PRs so I assume it is spurious.

Kobzol · 2025-08-15T18:08:47Z

Yes, it's indeed noise.

@rustbot label: +perf-regression-triaged

Mark-Simulacrum · 2025-08-19T02:20:34Z

The match-stress regression seems real, but probably not important to look into given the context of this PR.

RalfJung · 2025-08-19T05:58:13Z

I tried various things in this PR to avoid it and nothing helped 🤷 .

rustbot assigned fee1-dead Jul 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 28, 2025

RalfJung changed the title ~~Pattern valtrees~~ Patterns: represent constants as valtrees Jul 28, 2025

RalfJung commented Jul 28, 2025

View reviewed changes

tests/ui/thir-print/thir-tree-loop-match.stdout Outdated Show resolved Hide resolved

RalfJung commented Jul 28, 2025

View reviewed changes

RalfJung force-pushed the pattern-valtrees branch from ee610cc to b39c019 Compare July 28, 2025 16:33

RalfJung mentioned this pull request Jul 28, 2025

Raw Pointers are Constant PatKinds too #144573

Merged

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jul 28, 2025

Auto merge of #144591 - RalfJung:pattern-valtrees, r=<try>

e111586

Patterns: represent constants as valtrees

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 28, 2025

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 29, 2025

RalfJung force-pushed the pattern-valtrees branch from 52c6e8f to 1870bd2 Compare July 29, 2025 06:58

RalfJung commented Jul 29, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Jul 29, 2025

Auto merge of #144591 - RalfJung:pattern-valtrees, r=<try>

13cfa7a

Patterns: represent constants as valtrees

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 29, 2025

RalfJung and others added 7 commits August 14, 2025 09:39

PatKind: store constants as valtrees

3f1e99d

pattern testing: store constants as valtrees

d61fdbf

use ty::Value instead of manual pairs of types and valtrees

a171eaa

change StrLit type to ty::Value as well

a1acbfb

shrink TestBranch::Constant and PatRangeBoundary::Finite

dbc030e

avoid unnecessary type sanity checks

e2cc775

Apply suggestions from code review

2330afa

Co-authored-by: Boxy <[email protected]>

RalfJung force-pushed the pattern-valtrees branch from eacd56a to 2330afa Compare August 14, 2025 07:44

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 14, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 14, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 15, 2025

bors merged commit 8800ec1 into rust-lang:master Aug 15, 2025
11 checks passed

rustbot added this to the 1.91.0 milestone Aug 15, 2025

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 15, 2025

github-actions bot mentioned this pull request Aug 18, 2025

Toolchain upgrade to nightly-2025-08-18 flux-rs/flux#1249

Merged

RalfJung deleted the pattern-valtrees branch August 18, 2025 16:49

		let max = ty.numeric_max_val(cx.tcx).unwrap();
		let max = ty::ValTree::from_scalar_int(cx.tcx, max.try_to_scalar_int().unwrap());

Patterns: represent constants as valtrees #144591

Patterns: represent constants as valtrees #144591

Uh oh!

Conversation

RalfJung commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 28, 2025

Uh oh!

rustbot commented Jul 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jul 28, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jul 28, 2025

Uh oh!

rust-bors bot commented Jul 28, 2025

Uh oh!

This comment has been minimized.

BoxyUwU commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-timer commented Jul 29, 2025

Overall result: ✅ improvements - no action needed

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jul 29, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jul 29, 2025

Uh oh!

rust-bors bot commented Jul 29, 2025

Uh oh!

RalfJung commented Aug 14, 2025

Uh oh!

BoxyUwU commented Aug 14, 2025

Uh oh!

bors commented Aug 14, 2025

Uh oh!

BoxyUwU commented Aug 14, 2025

Uh oh!

bors commented Aug 15, 2025

Uh oh!

bors commented Aug 15, 2025

Uh oh!

Uh oh!

github-actions bot commented Aug 15, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented Aug 15, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

RalfJung commented Aug 15, 2025

Uh oh!

Kobzol commented Aug 15, 2025

Uh oh!

Mark-Simulacrum commented Aug 19, 2025

Uh oh!

RalfJung commented Aug 19, 2025

Uh oh!

Uh oh!

RalfJung commented Jul 28, 2025 •

edited

Loading

BoxyUwU Jul 29, 2025 •

edited

Loading

BoxyUwU Jul 29, 2025 •

edited

Loading

BoxyUwU commented Jul 29, 2025 •

edited

Loading